Agentic AI Threat Model: Top Identity Risks When Agents Act

For years, threat modelling has focused on what an AI system might say. The more important question now is what it can do.

Agentic AI risks change the equation. When an AI system can act, including initiating transactions, calling APIs, modifying records, and triggering downstream workflows, the traditional security conversation shifts from content risk to authority risk. As AI-driven threats evolve, teams can’t focus solely on model behavior or prompt injection. Instead, they need to model identity, delegated authority, tool trust, and operational ownership.

The most important change is not that the system can generate content, but that it can affect business state.

Here’s how to think about it systematically.

Key Takeaways:

• Agentic AI risks are authority risks. Threat models must cover identity, delegated authority, tool trust, and lifecycle governance, and not just model behavior or prompt misuse.
• Identity is the highest-leverage control surface. Distinct agent identities, scoped permissions, bounded delegation, and enforced approval paths close the gaps that shared accounts and standing privileges leave open.
• Risk spans the full lifecycle. Exposures introduced at provisioning and unresolved at decommissioning represent persistent attack surface that runtime monitoring alone won’t detect.
• Good controls produce auditable evidence. A control framework that cannot be verified by a security architect or audited by a compliance team is a set of assumptions and shouldn’t be regarded as a control framework.

What Belongs in an AI Agent Threat Model

Before assessing risk, teams need to inventory the system, not just the AI itself. Threat modelling fails when it stops at the model layer, leaving the surrounding identity and execution stack unexamined. A complete agentic AI threat model should account for:

• Agent runtime or orchestration layer: The platform or framework running the agent and coordinating its tasks.
• The model itself: The underlying AI and its capabilities, including what it can reason and act on.
• The owning team: Who provisioned the agent, who is responsible for its behavior, and who has the authority to modify or retire it.
• Credentials and non-human identities (NHIs): The service accounts, tokens, or certificates the agent uses to authenticate to other systems.
• Tools and APIs the agent can call: Every external system the agent can interact with and what permissions those integrations carry.
• Data the agent can access: Context feeds, memory stores, retrieval systems, and the sensitivity of the information within them.
• Approval paths: Whether any human is in the loop before consequential actions execute, and how bypass conditions are handled.
• Audit and rollback mechanisms: How agent actions are logged, whether they are attributable to a specific identity, and whether they can be reversed.

Skipping any of these steps leaves gaps. A team that audits the model but not the NHIs it uses, or the tools it can invoke, has mapped the surface but missed the exposure. Start with AI agent identity governance before you assess risk.

Top identity threats when agents act

In agentic systems, identity threats arise when AI agents operate without distinct identities, bounded authority, or auditable ownership. This is where non-human identity security becomes the highest-leverage investment a security team can make. The following risk categories map directly to controls, and each represents a failure mode that has already surfaced in early enterprise deployments.

No distinct agent identity

Many agentic systems run under shared service accounts originally provisioned for human workflows or other automation. When multiple agents share a credential, attribution breaks down. Incidents can’t be traced. Access reviews become guesswork. Assigning each agent a distinct, scoped identity is the foundational control and the one most commonly skipped at speed.

Excessive or standing privileges

Agents provisioned with broad permissions to handle edge cases often retain those permissions indefinitely. Standing access that an agent rarely exercises still represents continuous exposure. Least-privilege principles apply to NHIs the same way they do to human ones, but enforcement is less consistent. Agents accumulate permissions across iterations, and no one reviews the delta.

Broken delegation

An agent operating on a user’s behalf should carry only the authority that user has explicitly granted, and not the full permissions of the service account it operates under. When delegation is not clearly bounded and reviewed, an agent can exercise authority the user never intended to grant. This creates authorization gaps that are difficult to detect later.

Unmanaged lifecycle

Agents built for a specific workflow are often not decommissioned when that workflow changes. The agent stays active. The credentials stay valid. The connectors stay open. Orphaned agents represent a persistent, low-visibility attack surface. Stale credentials that survived a rotation cycle compound the risk. Lifecycle governance for AI systems requires the same rigor as it does for human accounts.

Excessive data and tool trust access

Agents built for a narrow task often have access to far more context than the task needs. A retrieval-augmented agent with access to the full document store can surface sensitive data outside its intended scope. Similarly, an agent authorized to read data may be able to invoke write-capable tools if too-level permissions are not scoped independently. Data access and tool trust are separate policy questions and should be governed separately.

Missing approval and separation-of-duties controls

For administrative, financial, or customer-impacting actions, human approval is a control and not a UX decision. Agentic systems that bypass approval gates for efficiency create unauthorized execution paths. The absence of separation-of-duties controls in automated workflows mirrors the same risk that exists in human financial processes, except the velocity is higher and the detection window is narrower.

Weak observability and audit

When agent actions aren’t fully logged, or logs are attributed to a shared account, incident response slows and governance reviews become assertions rather than evidence. Observability is a compliance requirement and a foundational element of any control framework for agentic AI.

Map the risks across the lifecycle

Agent risk doesn’t start and end at runtime. Security architecture that treats deployment as the beginning of the risk window will consistently miss exposures that originate earlier, and persist longer.

Design and provisioning

This is where identity decisions get made and where they most often get deferred. Weak identity assignment at launch means the entire subsequent lifecycle runs on a shaky foundation. Scope decisions made here determine what the agent can access from day one. Teams that skip a formal provisioning review are trading a five-minute decision for a six-month remediation.

Deployment

At deployment, the agent’s credential posture, tool access, and approval requirements should be confirmed against the original specification. Changes from design to deployment can introduce unintended permissions. Deployment gates should include an identity and access review, and a functional test.

Runtime

Runtime risk is where most threat models focus, and is where the most visible failures occur. Prompt injection, unexpected tool revocation, and privilege escalation through agent reasoning all happen here. But by runtime, the structural controls should already be in place. Runtime monitoring catches deviations from expected behavior but doesn’t substitute for pre-deployment architecture.

Change management

Permission creep during iteration is one of the most underestimated risk vectors in agentic AI. As capabilities expand, as new tools are added, as workflows change, permissions accumulate. Without a formal change review process that evaluates identity and access implications, incremental updates become incremental exposure.

Decommissioning

Agents that are retired without formal decommissioning leave credentials, connectors, and access paths active. Missing deprovisioning is one of the most consistent findings in early enterprise post-mortems on agentic deployments. Decommissioning should be a defined workflow with an identity and access checklist.

Lifecycle governance should feel like part of the security architecture and not a separate compliance exercise. This same rigor applied to human identity lifecycle management applies here.

What good controls look like

A well-constructed control framework for agentic AI addresses four domains:

1. Identity assignment and ownership
   Each agent has a distinct identity, a named owning team, and a defined scope. Identity is established at provisioning and carried through the lifecycle. Shared accounts aren’t allowed for agents operating in production environments.
2. Authorization and policy enforcement
   Least privilege policies govern both credential scope and tool access. Authorization is evaluated at provisioning and reviewed at defined intervals. Delegation is bounded, documented, and auditable. High-impact action classes require approval, and approval workflows are enforced by the system, not by convention.
3. Privileged access and escalation
   Agents that need elevated access for specific tasks should use just-in-time provisioning rather than standing privilege. Escalation paths are defined and logged. Anomalous escalation attempts trigger alerts rather than silent failure.
4. Audit, telemetry, and revocation and containment
   All agent actions are logged to a distinct identity. Logs include the tools invoked, the data accessed, the outcome, and any approval steps completed. Revocation workflows are tested before deployment, not after an incident. Audit evidence is sufficient to support both internal governance reviews and regulatory inquiries.

The goal is a controlled framework that a security architect can verify and a compliance team can audit without needing to understand the model’s internal behavior.

Learn how identity-first architecture applies these controls across agentic deployments, and explore Entrust AI security solutions built for the way agents operate.

Questions security teams should ask before deployment

Use the following questions to stress-test your AI agent threat model in design reviews, vendor evaluations, and governance assessments.

1. What are agentic AI risks?
2. How are agentic AI risks different from traditional AI risks?
3. What is an AI agent threat model?
4. Why is identity central to AI agent security?
5. What identity threats are most common in agentic AI systems?
6. Do AI agents need their own identities?
7. How should delegated authority be governed for AI agents?
8. What role do non-human identities play in agentic AI risk?
9. How do you audit and monitor AI agent actions?
10. What controls reduce identity risks when AI agents take action?

For more on the architectural implications, read The Agentic Enterprise Needs a New Control Plane.